Perhaps:
cf_apply_canvas(canvas)
cf_render(shader, material, mesh)

It still makes sense to have these two separated, as it’s common to render to the same canvas with different items (draw calls).

Annoyance: We already have render_ api in cute_draw.h so there’s a name clash, e.g. cf_render_to already exists. Maybe this new function could be named something else? cf_draw_elements might be a good name. People already tend to look for something named this anyways so it has some familiarity.

Another question is: What is the scope of states like scissor and viewport? Even in SDL_GPU, SDL_SetGPUScissor seems to imply that it affects the next draws onward until the pass is over but I haven't tested.

I don't really use viewport but scissor is how GUI libraries implement scrolling containers.

Scissor limits what area of the screen can be drawn to. Anything outside will be clipped. This is the best graphical explanation: https://gamedev.stackexchange.com/a/167051.

UI libraries tend to use it for scrolling elements because that's the most straightforward way to do things like: Draw half a sprite or half of a character due to scrolling.
Of course, totally out of view elements should not even be drawn but those that straddles the scroll border do not have to be treated specially by CPU code. Just draw them as usual and they will be clipped.

I'm not really sure if state persists (it probably doesn't in SDL_Gpu, but also who cares I suppose), I intended to implement as always setting the scissor for each draw call, same for viewport. It's simpler this way and probably more cross-platform. As in, the backend implementations always set those each draw call.